So a back end mainly defines either a protocol (the
nntp back end accesses news via
NNTP, the nnimap back end
accesses mail via IMAP) or a file format
and directory layout (the nnspool back end
accesses news via the common “spool directory”
format, the nnml back end access mail via a file
format and directory layout that's quite similar).
Gnus does not handle the underlying media, so to speak—this is all done by the back ends. A back end is a collection of functions to access the articles.
However, sometimes the term “back end” is also
used where “server” would have been more
appropriate. And then there is the term “select
method” which can mean either. The Gnus terminology can
be quite confusing.
nntp back end Gnus uses the ones
that the NNTP server makes, but Gnus makes
them by itself for some backends (in particular,
nnml).
When Gnus enters a group, it asks the back end for the headers of all unread articles in the group. Most servers support the News OverView format, which is more compact and much faster to read and parse than the normal head format.
The NOV data consist of one or more text lines (see Motion by Text Lines) where each line has the header information of one article. The header information is a tab-separated series of the header's contents including an article number, a subject, an author, a date, a message-id, references, etc.
Those data enable Gnus to generate summary lines quickly.
However, if the server does not support
NOV or you disable it purposely or for
some reason, Gnus will try to generate the header information
by parsing each article's headers one by one. It will take
time. Therefore, it is not usually a good idea to set
nn*-nov-is-evil (see
Slow/Expensive Connection) to a non-nil
value unless you know that the server makes wrong
NOV data.
gnus-build-sparse-threads has been switched
on.